When software programs are shipped overseas or installed at various customer sites, the developers of software programs may implement some security measures to ensure that only the authorized parties access the software programs. This may be implemented, for example, by employing certain access restrictions that are attached to the software. The access restrictions indicate which clients/end users are authorized to access specified portions of a program. When a particular client is identified, the client's credentials may be compared to the access restrictions to determine whether the client is an authorized party capable of accessing the entire program or particular portions of the program.
In some cases, creators and/or distributors of executable software may wish to restrict access to particular portions of software for legal purposes. For example, current United States of America export restrictions on cryptographic products do not allow an open and documented application programming interface (API) that has a pluggable implementation into an encryption framework (i.e., the API cannot be plugged into and taken out of various frameworks). While API developers want to export all the software as one package for multiple types of cryptographic products and multiple cryptographic algorithms, export restrictions require that software for cryptographic products is restricted such that particular consumers (i.e., end users) may access only specific approved cryptographic algorithms.
One approach to restrict users from using functionalities provided in executable files involves cryptography, where data is scrambled, or encrypted, for secure transfer across the network. Cryptography can be employed, for example, using the IPsec (Internet Protocol security) protocol to securely transfer data between computers across the network. Cryptography is also commonly employed using the SSL (Secure Sockets Layer) protocol to encrypt Web-based traffic, such as data sent over e-commerce sites, portals, or secure mail servers.
Conventionally, a common option to restrict software involves closing one end of the framework interface (i.e., either close the end from the end user or the end from the cryptographic providers) and do not include the documentation for the closed interface. However, this does not allow both consumers and providers to have access to the software. Another option is to restrict portions of code provided in the software. In some instances, this option may not be suitable because third parties would not be able to modify the restricted portions or provide additional software algorithms.